* In re MeLampy et al 

Serial No.: 09/844,964 

THE CLAIMS 

These claims reflect the pending claims in the above-referenced application. 

1 1. (Currently Amended) A system for controlling real-time transport protocol flow 

2 through multiple networks via use of a media flow routing, comprising: 

3 a first computer connected to a second computer, via a plurality of associated computers, 

4 wherein each of said first computer, said second computer, and said plurality of associated 

5 computers comprise^] : 

6 a transceiver; 

7 software stored therein defining functions to be performed; and 

8 a processor configured by said software to perform the steps of[?] : 

9 performing an inbound screen on route information received from said 

10 second computer, to determine if said received route information should be discarded, 

1 1 if said route information is not discarded, comparing said received and 

12 screened route information to a local policy defined within said first computer; and 

13 selecting a primary route from said received route information and local 

14 route information in accordance with said local policy, wherein said primary route is a path from 

15 said first computer to said second computer via said plurality of associated computers. 

1 2. (Original) The system of claim 1 , wherein each of said plurality of associated 

2 computers is capable of receiving said received and screened route information and transmitting 

3 said information to another of said plurality of associated computers in a path to said second 

4 computer, such that a real-time transport protocol flow is divided between each of said plurality 
. 5 of associated computers. 

1 3. (Original) The system of claim 1, wherein said received route information is 

2 provided within a telephony routing over Internet protocol (TRIP) update message. 
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1 4. (Original) The system of claim 1, wherein said local policy is stored on a storage 

2 unit that is capable of storing internal route information and route information from said received 

3 and screened route information. 

1 5. (Original) The system of claim 4, wherein each of said computers is further 

2 configured by their respective software to perform the step of, selecting a primary route from a 

3 group of routes comprising said internal route information and said received and screened route 

4 information. 

1 6. (Original) The system of claim 5, wherein said processor is further configured by 

2 said software to perform the step of, processing a received session initiation protocol (SIP) invite 

3 message that is received on said primary route. 

1 7. (Original) The system of claim 5, wherein said processor is further configured by 

2 said software to perform the step of, performing an outbound screen on said received and 

3 screened information prior to transmitting said received and screened information to said first 

4 computer, wherein said outbound screen is performed on said primary route prior to said 

5 transceiver transmitting said primary route. 

1 8. (Original) The system of claim 1, wherein said local policy comprises an activate 

2 date and time field that defines a date and time for said local policy to be enabled by said 

3 processor. 

1 9. (Original) The system of claim 1, wherein said local policy comprises a de- 

2 activate date and time field that defines a date and time for said local policy to be disabled by 

3 said processor. 

1 1 0. (Original) The system of claim 1 , wherein said local policy comprises an origin 

2 field. 
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1 11. (Original) The system of claim 1 0, wherein said processor is further configured 

2 by said memory to perform the function of, comparing said origin field within said local policy to 

3 an origin attribute comprised by said received route information, if said received route 

4 information comprises said origin attribute, and utilizing said local policy if said origin attribute 

5 at least partially matches said origin field. 

1 12. (Original) The system of claim 3, wherein said processor is further configured by 

2 said memory to perform the function of, utilizing said local policy if said TRIP update message 

3 does not comprise an origin attribute. 



1 13. (Original) The system of claim 11, wherein the format of said origin attribute and 

2 said origin field conforms to E.164 style addresses, Internet style addresses, and, SIP telephone 

3 addresses or non-SIP telephone addresses. 

1 14. (Original) The system of claim 1, wherein said local policy comprises a 

2 destination field. 



1 15. (Original) The system of claim 14, wherein said processor is further configured 

2 by said software to perform the step of, comparing said destination field within said local policy 

3 to a destination attribute within said received route information, if said received route 

4 information comprises said destination attribute, and utilizing said local policy if said destination 

5 attribute at least partially matches said destination field. 

1 16. (Original) The system of claim 15, wherein the format of said destination 

2 attribute and said destination field conforms to E.164 style addresses, Internet style addresses, 

3 SIP telephone addresses, or non-SIP telephone addresses. 

1 17. (Original) The system of claim 1, wherein said local policy comprises a carrier 

2 field that identifies a number of carriers from which said route information will be accepted. 
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1 18. (Original) The system of claim 17, wherein said processor is further configured 

2 by said software to perform the step of, discarding said received route information if a carrier 

3 attribute comprised by said received route information does not match at least one carrier 

4 identified by said carrier field. 

1 19. (Original) The system of claim 1, wherein said local policy comprises a cost field 

2 that identifies an acceptable range of cost to be billed for use of a route. 



1 20. (Original) The system of claim 19, wherein said processor is further configured 

2 by said software to perform the step of, discarding said received route information if a cost 

3 attribute comprised by said received route information does not fall within said acceptable range 

4 of cost identified by said cost field. 



1 21. (Original) The system of claim 1 , wherein said local policy comprises a quality of 

2 service (QoS) field that identifies an acceptable range of QoS associated with use of a route. 

1 22. (Original) The system of claim 21, wherein said processor is further configured 

2 by said software to perform the step of, discarding said received route information if a QoS 

3 attribute within said received route information does not fall within said acceptable range of QoS 

4 cost identified by said QoS field. 
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1 23. (Original) A method of controlling real-time transport protocol flow via use of 

2 media flow routing, comprising the steps of: 

3 receiving information regarding a route from a first computer to a second computer, via a 

4 plurality of associated computers; 

5 performing an inbound screen on said route information received from said first 

6 computer, to determine if said received route information should be discarded; 

7 if said route information is not discarded, comparing said received and screened route 

8 information to a local policy; and 

9 selecting a primary route from said received route information and local route information 

10 in accordance with said local policy, wherein said primary route is a path from said second 

1 1 computer to said first computer via said plurality of associated computers. 

1 24. (Original) The method of claim 23, wherein said route is for ranges conformed to 

2 E.164 style numbering, Internet style addresses of endpoints, SIP telephone addresses, or non-SIP 

3 telephone addresses. 



1 25. (Original) The method of claim 23, wherein each of said plurality of associated 

2 computers is capable of receiving said received and screened route information and transmitting 

3 said information to another of said plurality of computers in a path to said first computer, such 

4 that a real-time transport protocol flow is divided between each of said plurality of associated 

5 computers. 

1 26. (Original) The method of claim 23, further comprising the step of processing a 

2 received session initiation protocol (SIP) invite message that is received on said primary route. 

1 27. (Original) The method of claim 23, further comprising the step of performing an 

2 outbound screen on said received and screened information prior to transmitting said received 

3 and screened information, wherein said outbound screen is performed on said primary route prior 

4 to transmitting said route. 



7 



In re MeLampy et al 
Serial No.: 09/844,964 



1 28. (Original) The method of claim 23, further comprising the step of enabling said 

2 local policy on a specified date and at a specified time in accordance with an activate date and 

3 time field defined by said local policy. 

1 29. (Original) The method of claim 23, further comprising the step of disabling said 

2 local policy on a specified date and at a specified time in accordance with a de-activate date and 

3 time field defined by said local policy. 

1 30. (Original) The method of claim 23, wherein said local policy comprises an origin 

2 field. 

1 31. (Original) The method of claim 30, further comprising the step of comparing said 

2 origin field within said local policy to an origin attribute comprised by said received route 

3 information, if said received route information comprises said origin attribute, and utilizing said 

4 local policy if said origin attribute at least partially matches said origin field. 



1 32. (Original) The method of claim 3 1 , wherein the format of said origin attribute 

2 and said origin field conforms to E.164 style addresses, Internet style addresses, SIP telephone 

3 addresses, or non-SIP telephone addresses. 

1 33. (Original) The method of claim 23, wherein said route information is provided 

2 within a telephony routing over Internet protocol (TRIP) update message. 

1 34. (Original) The method of claim 23, wherein said local policy comprises a 

2 destination field. 
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1 35. (Original) The method of claim 34, further comprising the step of comparing said 

2 destination field within said local policy to a destination attribute within said received route 

3 information, if said received route information comprises said destination attribute, and utilizing 

4 said local policy if said destination attribute at least partially matches said destination field. 

1 36. (Original) The method of claim 3 1 , wherein the format of said destination 

2 attribute and said destination field conforms to E.164 style addresses, Internet style addresses, 

3 SIP telephone addresses, or non-SEP telephone addresses. 

1 37. (Original) The method of claim 23, wherein said local policy comprises a carrier 

2 field that identifies a number of carriers from which said route information will be accepted. 

1 38. (Original) The method of claim 37, further comprising the step of discarding said 

2 received route information if a carrier attribute comprised by said received route information 

3 does not match at least one carrier identified by said carrier field. 

1 39. (Original) The method of claim 23, wherein said local policy comprises a cost 

2 field that identifies an acceptable range of cost to be billed for use of a route. 

l 40. (Original) The method of claim 39, further comprising the step of discarding said 

. 2 received route information if a cost attribute with said received route information does not fall 

3 within said acceptable range of cost identified by said cost field. 

1 41. (Original) The method of claim 23, wherein said local policy comprises a quality 

2 of service (QoS) field that identifies an acceptable range of QoS associated with use of a route. 

1 42. (Original) The system of claim 41, further comprising the step of discarding said 

2 received route information if a QoS attribute comprised by said received route information does 

3 not fall within said acceptable range of QoS cost identified by said QoS field. 
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1 43. (Original) A system for controlling real-time transport protocol flow via use of 

2 media flow routing, comprising: 

3 means for receiving information regarding a route from a first computer to a second 

4 computer, via a plurality of associated computers; 

5 means for performing an inbound screen on said received route information from said 

6 first computer which determines if said received route information should be discarded; 

7 means for comparing said received and screened route information to a local policy stored 

8 within said second computer if said route information is not discarded; and 

9 means for selecting a primary route from said received route information and local route 

10 information in accordance with said local policy, wherein said primary route is a path from said 

1 1 second computer to said first computer via said plurality of associated computers. 

1 44. (Original) The system of claim 43, wherein said route is for ranges conformed 

2 to E.164 style numbering, Internet style addresses of endpoints, SIP telephone addresses, and 

3 non-SIP telephone addresses. 

1 45. (Original) The system of claim 43, wherein each of said plurality of associated 



2 computers is capable of receiving said received and screened route information and transmitting 

3 said information to another of said associated computers in a path to said first computer, such 

4 that a real-time transport protocol flow is divided between each of said plurality of associated 

5 computers. 

1 46. (Original) The system of claim 43, further comprising a means for processing a 

2 received session initiation protocol (SIP) invite message that is received on said primary route. 
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1 47. (Original) The system of claim 43, further comprising a means for performing an 

2 outbound screen on said received and screened information, which performs said outbound 

3 screen prior to transmitting said received and screened information to said first computer and 

4 wherein said means for performing an outbound screen performs outbound screening on said 

5 primary route prior to transmitting said primary route. 

1 48. (Original) The system of claim 43, further comprising a means for enabling said 

2 local policy on a specified date and at a specified time in accordance with an activate date and 

3 time field defined by said local policy. 

1 49. (Original) The system of claim 43, further comprising a means for disabling said 

2 local policy on a specified date and at a specified time in accordance with a de-activate date and 

3 time field defined by said local policy. 

1 50. (Original) The system of claim 43, wherein said local policy comprises an origin 

2 field. 

1 51. (Original) The system of claim 50, further comprising a means for comparing 

2 said origin field within said local policy to an origin attribute within said received route 

3 information, wherein said means for comparing compares if said received route information 

4 comprises said origin attribute, and utilizes said local policy if said origin attribute at least 

5 partially matches said origin field. 

1 52. (Original) The system of claim 5 1 , wherein the format of said origin attribute and 

2 said origin field conforms to E.164 style addresses, Internet style addresses, SIP telephone 

3 addresses, or non-SIP telephone addresses. 

1 53. (Original) The system of claim 43, wherein said route information is provided 

2 within a telephony routing over Internet protocol (TRIP) update message. 
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1 54. (Original) The system of claim 43, wherein said local policy comprises a 

2 destination field. 

1 55. (Original) The system of claim 54, further comprising a means for comparing 

2 said destination field within said local policy to a destination attribute within said received route 

3 information, wherein said means for comparing compares if said received route information 

4 comprises said destination attribute, and utilizes said local policy if said destination attribute at 

5 least partially matches said destination field. 

1 56. (Original) The system of claim 51, wherein the format of said destination 

2 attribute and said destination field conforms to E.164 style addresses, Internet style addresses, 
. 3 SIP telephone addresses, or non-SIP telephone addresses. 

1 57. (Original) The system of claim 53, wherein said local policy comprises a carrier 

2 field that identifies a number of carriers from which said route information will be accepted. 

1 58. (Original) The system of claim 57, further comprising a means for discarding said 

2 received route information if a carrier attribute within said received route information does not 

3 match at least one carrier identified by said carrier field. 

1 59. (Original) The system of claim 43, wherein said local policy comprises a cost 

2 field that identifies an acceptable range of cost to be billed for use of a route. 

1 60. (Original) The system of claim 59, further comprising a means for discarding said 

2 received route information if a cost attribute within said received route information does not fall 

3 within said acceptable range of cost identified by said cost field. 
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1 61 . (Original) The system of claim 43, wherein said local policy comprises a quality 

2 of service (QoS) field that identifies an acceptable range of QoS associated with use of a route. 

1 62. (Original) The system of claim 61, further comprising a means for discarding said 

2 received route information if a QoS attribute within said received route information does not fall 

3 within said acceptable range of QoS cost identified by said QoS field. 
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